Please address the comments from this code review:
## Individual Comments

### Comment 1
<location> `src/usb_hid.rs:107` </location>
<code_context>
+    {
+        written = 0;
+
+        while written < data.len() {
+            let new_data: &[u8] = &prepend_byte_and_offset(data, written);
+            let n = device.write(new_data).context("write payload")?;
+            written = written + n - 1;
</code_context>

<issue_to_address>
Potential buffer overrun in chunked write loop.

If less than 64 bytes remain, slicing 'data[offset..offset + 64]' will panic. Please handle the final chunk to prevent out-of-bounds access.
</issue_to_address>

Please address the comments from this code review:
## Overall Comments
- The write loop on Windows subtracts 1 from each write count, so if device.write ever returns 0 or 1 this could spin indefinitely—consider erroring or breaking out when n <= 1 to avoid infinite loops.
- The hardcoded report ID (0x0) in prepend_byte_and_offset limits flexibility—consider parameterizing this value or documenting its assumptions for different HID devices.
- You might extract the chunking and packet-preparation into a reusable iterator or helper struct to make the write logic more declarative and testable, reducing manual loop complexity.

## Individual Comments

### Comment 1
<location> `src/usb_hid.rs:107` </location>
<code_context>
+    {
+        written = 0;
+
+        while written < data.len() {
+            let new_data: &[u8] = &prepend_byte_and_offset(data, written);
+            let n = device.write(new_data).context("write payload")?;
</code_context>

<issue_to_address>
Potential for infinite loop if device.write returns 1.

Since written does not increase when device.write returns 1, the loop may never terminate. Please add a check or safeguard for this scenario.
</issue_to_address>

### Comment 2
<location> `src/usb_hid.rs:128` </location>
<code_context>
     Ok(())
 }
+
+fn prepend_byte_and_offset(data: &[u8], offset: usize) -> [u8; 65] {
+    let mut result: [u8; 65] = [0u8; 65];
+    result[1] = 0x0;
</code_context>

<issue_to_address>
Possible out-of-bounds panic if offset > data.len().

Add a debug assertion or explicit check to ensure offset does not exceed data.len().
</issue_to_address>

Please address the comments from this code review:
## Individual Comments

### Comment 1
<location> `src/usb_hid.rs:107` </location>
<code_context>
+    {
+        written = 0;
+
+        while written < data.len() {
+            let new_data: &[u8] = &prepend_byte_and_offset(data, written);
+            let n = device.write(new_data).context("write payload")?;
+            written = written + n - 1;
+        }
+    }
</code_context>

<issue_to_address>
Potential off-by-one error in written byte calculation.

Subtracting 1 from 'written + n' may cause incorrect loop termination or skipped bytes, particularly when 'n' is 0 or 1. Please verify if this adjustment is needed.
</issue_to_address>

### Comment 2
<location> `src/usb_hid.rs:131` </location>
<code_context>
+fn prepend_byte_and_offset(data: &[u8], offset: usize) -> [u8; 65] {
+    let mut result: [u8; 65] = [0u8; 65];
+    result[1] = 0x0;
+    if offset > data.len() {
+        return result;
+    }
+    if data.len() - offset < 64 {
</code_context>

<issue_to_address>
Returning a zeroed buffer when offset exceeds data length may mask errors.

Returning a zeroed buffer in this case may hide upstream logic errors. Instead, consider returning an error or panicking to make the issue explicit.
</issue_to_address>